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Addendum to RFC 987 


(Mapping between X.400 and RFC-822) 


Status of this Memo 


This RFC suggest a proposed protocol for the Internet community, and 
requests discussion and suggestions for improvements. Distribution 
of this memo is unlimited. 


This document specifies a number of additions and corrections to 
RFC-987, aka Mailgroup Note 19. 


The addendum carries equal weight to the original specification, 
which must be used when this mapping is performed on the Internet or 
in the UK Academic Community. This mapping may also be used within 
the RARE community in Europe. This specification may be modified in 
the light of implementation experience, but no substantial changes 
are expected. 


ise Errata 
- In section 4.6.4, replace ".." with ".". 


- In section 4.2.4, replace three references to 4.3.1 by 
4.2.1, and one reference to 4.2.2 by 4.1.2. 


= In section 5.2, replace "1 mailbox" with "lfmailbox", 
"1 msg-id" with "l#msg-id" and "1 encoded-type" with 
"l#encoded-type". 


2. Component Ordering 


In most cases, ordering of O/R name components is not significant for 


the mappings specified by this document. However, Organisational 
Units and Domain Defined Attributes are specified as SEOUENCE, in 
P1.ORName, and so their order may be significant. This specification 


needs to take account of this in two ways: 
1) To allow consistent mapping into the domain hierarchy 


2) To ensure preservation of order over multiple mappings. 
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There are three places where an order must be specified: 


1) On the text encoding (std-orname) of P1.ORName as used in the 
local-part of an RFC-822 address, the most significant component 
must be on the RHS. This applies only to those components which 
may have multiple values (Organisational Unit, and Domain 
Defined Attributes). Other attributes may be presented in any 
order. Note that in dmn-orname specified in Appendix F, this 
ordering is already implied by the current ordering 
requirements. 


2) For the Organisational Units (OU) in P1.ORName, the first OU in 
the SEQUENCE is the most signicicant. This follows the 
"natural" hierarchy of the specification of P1.0RName, where the 
most significant components are defined first. 


3) For the Domain Defined Attributes in P1.0RName, the First Domain 
Defined Attribute in the SEQUENCE is the most significant. 


Note that although the ordering defined in 2) and 3) is mandatory for 
this mapping, there are NO implications on ordering significance 
within X.400. 


3. Extensions To Deal with Omitted Components 


Implementation of RFC-987 has proved to be a little inflexible for 
some naming strategies. In particular, there are some difficulties 
where Organisation or PRMD is omitted: 


The following sentence of RFC-987 should be removed: 4.2.1 (Page 27): 
"If one of the hierarchical components is omitted .... tuple).". 


The strategy proposed is to introduce the concept of explicit missing 
components to the symmetrical mapping described in 4.2.1. 
Essentially, a domain may be associated with an omitted attribute in 
conjuction with several present ones. When performing the 
algorithmic insertion of components lower in the hierarchy, the 
omitted value should be skipped. For example, if "GMD.DFN" is 
associated with "C=DE", "ADMD=DBP", "PRMD=GMD", and omitted 
organisation, then "ZI.GMD.DFN" is mapped with "C=DE", "ADMD=DBP", 
"PRMD=GMD", "OU=ZI". It should be noted that attributes may have 
null values, and that this is treated separately from omitted 
attributes (whilst it would be bad practice to treat these two cases 
differently, they must be allowed for in practice). 
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To allow the mapping of null 
specification of Appendix F, 
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organisations to be represented in the 
so 
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the dmn-orname syntax is extended, 
symbol "G" (not a printable string 
to an omitted attribute. The new 


that values may be given the 
character). This corresponds 
definition is: 


dmn-orname = dmn-part *( "." dmn-part ) 
dmn-part = attribute "$" value 
attribute = standard-type 

/ "7" dmn-printablestring 
value = dmn-printablestring 

/ "(a " 


dmn-printablestring 
*( dmn-char / dmn-pair ) 
= <ps-delim, and any ps-char except 


dmn-char " 


dmn-pair 
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Appendix F - Format of address mapping tables 
A new Appendix F is defined as follows: 


There is a need to specify the association between the domain and 
X.400 namespaces described in 4.2.1. This is defined as a table 
syntax, but the syntax is defined in a manner which makes it suitable 
for use with domain nameservices (such as the Internet Domain 
nameservers or the UK NRS). The mapping is not symmetric, and so a 
separate table is specified for each direction. If multiple matches 
are possible, the longest possible match should be used. 


Various restrictions are placed on the usage of dmn-orname: 


1) Only C, ADMD, PRMD, O, and OU may be used. 

2) There must be a strict ordering of all components, with the most 
significant components on the RHS. 

3) No components may be omitted from the hierarchy, although the 


hierarchy may terminate at any level. 
omitted component, the "@" 


If the mapping is to an 
syntax is used. 


For domain -> X.400: 
domain-syntax "#" dmn-orname "#" 


Note that the trailing "#" is used for clarity, 
syntax can lead to values with trailing blanks. 


as the dmn-orname 


For example: 


AC.UK#PRMDSDES.ADMDSBT.CSUK# 
XEROX. COM#0$Xerox.ADMDSATT.CSUS# 
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HMI .DBP.DFN#OS@.PRMDSHMI.ADMD.DBP.CSDE# 
For X.400 -> domain: 


dmn-orname "#" domain-syntax "#" 
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